home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19941031-19941221
/
000299_news@columbia.edu_Tue Nov 29 14:16:25 1994.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
2KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA27228
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Tue, 29 Nov 1994 09:16:40 -0500
Received: by apakabar.cc.columbia.edu id AA16030
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Tue, 29 Nov 1994 09:16:38 -0500
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: MSKerm 3.14 BETA 14- APC security too strong?
Date: 29 Nov 1994 14:16:25 GMT
Organization: Columbia University
Lines: 32
Message-Id: <3bfd3p$fkg@apakabar.cc.columbia.edu>
References: <jhurwitD00M19.MnM@netcom.com>
Nntp-Posting-Host: watsun.cc.columbia.edu
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <jhurwitD00M19.MnM@netcom.com>,
Jeffrey Hurwit <jhurwit@netcom.com> wrote:
> I have a pair of scripts (one on the host, one on my PC) for
> downloading a compressed backup archive. I usually keep terminal
> apc set to on, but need it to be set to unchecked for this one
> script. I was able to do this automatically with MS-Kermit 3.13,
> because it would accept a 'set term apc unchecked' command sent as
> an apc from the host. With 3.14, trying to do this produces a
> '?Word "unchecked" not usable here' error. Isn't this a little bit
> too much security? Can someone suggest a workaround (besides
> manually changing the settings, which defeats the point of having a
> script to do it all automatically)? TIA for your help,
>
We get this complaint a lot, but there is no easy solution. There is a
basic conflict between the need for host-directed operations such as
your script and the need to protect all MS-DOS Kermit users from
malicious attacks.
If SET TERMINAL APC UNCHECKED could be issued by the host application,
then there would *be* no security.
On balance, I think most would agree that inconvenience weighs less
than disaster.
You should think of SET TERMINAL APC UNCHECKED the same way you think
about passwords. You don't put passwords in scripts because the risk
far outweighs the convenience. Thus whenever you run your login script,
you have it prompt you for your password. Similarly, you shoul SET TERM
APC UNCHECKED before running your script and then put it back to ON
afterwards.
- Frank